Persistence is a property related to programming languages by which created objects continue to exist and variables continue to retain their values between runs of a program. Persistence allows data to have lifetimes that vary from transient to indefinite. Thus, persistence is particularly important in internet-programming languages, object-oriented databases, and data warehousing. Persistent programming languages offer an alternative to applications that require more than traditional database support.
Persistence in a programming language, the Java language for example, allows all kinds of objects to have the same available lifetimes. An orthogonally persistent variant of the Java platform, Persistent Java (PJava), simplifies the task of developers if a Java application involves objects constructed at runtime, and those objects are needed during more than one invocation of the application. But orthogonal persistence in PJava does not address all applications, such as applications for which a relational data model and structured query language are important.
Further developments have attempted to broaden the types of data and objects that may be given persistence. Within the Java environment, extensions have been added to PJava to provide limited transparent access to legacy data such as files and relational data systems. Java data base manager (JDBM) is a transactional persistence engine for Java. JDBM can store a mix of objects, and updates are done in a transactionally safe manner. JDBM also provides scalable data structures to support persistence of large object collections.
Java “Reflection” is a mechanism that allows Java to map “runtime type information” of objects during program execution. A class library deciphers the properties and methods of unknown objects during runtime. The Reflection mechanism, however, is limited to the Java environment.
The need to impart persistence to diverse types of objects has resulted in information organization structures, or “metadata.” Meta Content Framework (MCF) is a structure description language. An MCF database is a set of directed labeled graphs (DLGs) including a set of labels (property types), a set of nodes, and a set of arcs (properties). Nodes can represent items such as web pages, images, subject categories, sites, people, places, and events. DLGs seek to attach properties to nodes and property types thereby allowing MCF to be its own data schema definition language.
The Object Management Group's Meta Object Facility (MOF) is a specification for describing and defining metadata. The Common Warehouse Metamodel (CWM) provides a common meta-model with syntax and semantics for dynamic data warehousing operations. Both MOF and CWM focus on compile-time models of data and metadata from which interfaces and code are derived. Changes to compile-time models of data and metadata require restarting the host system.
Microsoft Repository has a relational database for storing object properties and relationships. The engine manages the database and provides basic functions of data storage and retrieval. The technology may be used for defining compile-time, but not runtime, data models for software development.
Traditionally, a software component's persistent data model must be known at system compilation time. Those elements of the model (e.g., entities, relationships, attributes, and values) must be well defined so that the appropriate data access and storage schemes can be developed for each software component prior to system runtime. Any changes to a component's data model, as well as introduction of new components into the system, typically require placing the system into an inactive state while the new data models are incorporated. This incorporation may include recompilation of existing system components or introduction of new system components involved in the system's overall data management scheme. This results in a maintenance cycle with undesirable human intervention. The system must be taken out of service, necessary coding and testing must be performed, and the system has to be restarted.
Specifically, when an object is first made persistent in a store, the class of the object including the bytecodes is also made persistent and the object bound to the persistent instance of the class. When changes are made to source code in the file system, and the code is recompiled generating a new class file, the changes have no effect on the behavior of the objects in the persistent store. Modifying the class in the persistent store requires the additional step of inactivating the system, and repairing the class in the persistent store, or deleting the persistent store and recreating it from scratch. In a high availability environment, this is usually unacceptable. What is needed is seamless integration of new persistent data models without compromising the availability of the running system.